REMARKS 

Claims 17-24, 26-30, 32, 44-46, 48, 49, 54, 60-62, and 68-70 are pending in the 
application. Claims 17-24, 26-30, 32, 44-46, 48, 49, 54, 60-62, and 68-70 stand rejected under 
35 U.S.C. § 1 12, % 2 as indefinite for failing to particularly point out and distinctly claim the 
subject matter that the Applicant regards as the invention. Claims 17-24, 26-30, 32, 44-46, 48, 
49, 54, 60-62, and 68-70 stand rejected under 35 U.S.C. § 101 because the claimed invention is 
directed to non-statutory subject matter. Claims 17, 18, 20, 26, 44, 45, 60, 61, and 68-70 stand 
rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent Application Publication 
No. 2003/0065546 to Gorur et al. in view of "Design and Performance of a General-Purpose 
Software Cache" by Iyengar (hereinafter "Iyengar"). Claims 19, 21-24, 27-30, 32, 46, 48, and 49 
stand rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent Application 
Publication No. 2003/0065546 to Gorur et al. in view of Iyengar and U.S. Patent Application 
Publication No. 2002/0091539 to Yin et al. Claims 54 and 62 stand rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over U.S. Patent Application Publication No. 2003/0065546 to 
Gorur et al. in view of Iyengar, U.S. Patent Application Publication No. 2002/0091539 to Yin et 
al, and "Pi: A New Approach to Flexibility in System Software" to Kulkarni (hereinafter 
"Kulkarni"). 

Reconsideration is requested. The rejections are traversed. No new matter is added. 
Claims 17 and 44 are amended. Claims 17-24, 26-30, 32, 44-46, 48, 49, 54, 60-62, and 68-70 
remain in the case for consideration. 

CLAIM REJECTIONS - 35 U.S.C. § 1 12 
Claims 17-24, 26-30, 32, 44-46, 48, 49, 54, 60-62, and 68-70 stand rejected under 35 
U.S.C. § 1 12, second paragraph, as being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. The Applicant 
believes the amendments to claims 17 and 44 address these rejections. Support for these 
amendments can be found in the specification at page 9, lines 10-11 and 31-32. The Applicant 
believes that claims 17-24, 26-30, 32, 44-46, 48, 49, 54, 60-62, and 68-70 are now patentable 
under 35 U.S.C. § 112, second paragraph. 
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The Applicant would also like to clarify that the phrase "at least" recited in claim 17, line 
12, is meant to modify both "the contract object and the second object". Therefore, there is a 
proper antecedent basis in claim 17, line 12. 

CLAIM REJECTIONS - 35 U.S.C. § 101 
Claims 17-24, 26-30, 32, 44-46, 48, 49, 54, 60-62, and 68-70 stand rejected under 35 
U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. 

Claim 17 is amended to recite "A computer-implemented method for using a contract 
object to coordinate relationships between multiple objects, comprising: ... recording an entry in 
a transaction log, the entry representing that the contract object is created to relate the first object 
and the second object; and removing the entry from the transaction log after the contract object is 
created." Claim 44 includes similar features. Support for this amendment can be found in the 
specification at page 1, lines 9-10, and page 9, lines 10-11 and 31-32. 

The Examiner acknowledges that the intermediate step of "updating ... the contract 
object" produces a useful, concrete, and tangible result (see Office Action dated March 26, 2007, 
page 3, paragraph 9). But the Examiner alleges that the features of recording and removal of an 
entry does not produce any useful, concrete, and tangible result (see Office Action dated March 
26, 2007, page 3, paragraph 9). The Examiner argues that the claimed invention as a whole does 
not produce a "useful, concrete, and tangible result", citing State Street Bank & Trust Co. v. 
Signature Financial Group Inc., 149 F.3d 1368, 47 U.S.P.Q.2d 1596 (Fed. Cir. 1998) (see Office 
Action dated March 26, 2007, page 3, paragraph 9). The Applicant respectfully disagrees for the 
reasons that follow. 

According to State Street Bank & Trust Co. v. Signature Financial Group Inc., the 
claimed invention must produce a "useful, concrete, and tangible result." Claims 17 and 44 have 
been amended to describe the claims as creating a contract object and using the contract object to 
coordinate relationships between multiple objects. The Applicant asserts that such amendment 
should make the claims allowable, as they produce a useful, concrete, and tangible, and concrete 
result: namely, a contract object is created to coordinate relationships between multiple objects, 
resulting in an automatic update to one object when an event occurs to another object. 
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Useful 

According to the Interim Guidelines for subject matter eligibility, published on 
November 22, 2005, "[f]or an invention to be "useful" it must satisfy the utility requirement of 
section 101" (see Interim Guidelines, page 20). A contract object is created to provide 
associations between multiple objects for many applications, such as file systems, relational 
databases, and spreadsheets. For example, one object (the "referencing" object) may reference 
another object (the "referenced" object) stored elsewhere in the software environment. If the 
"referenced" object is changed, e.g., deleted, moved, the "referencing" object might need to 
change, too. But often there is no way to determine what "referencing" objects might be affected 
by the changes to the "referenced" object. The contract object is useful to provide associations 
between multiple objects, such that when a first event (e.g., deleted or moved) occurs to a first 
object, a second object may access the contract object to effect any corresponding changes 
according to the first event. 

Tangible 

According to the Interim Guidelines for subject matter eligibility, published on 
November 22, 2005, the requirement that the result be "tangible" means that "the process claim 
must set forth a practical application of that § 101 judicial exception to produce a real-world 
result. ... In other words, the opposite meaning of 'tangible' is 'abstract'" (see Interim 
Guidelines, pages 21-22). The Applicant believes that the use of a contract object produces a 
"real-world result". That is, the contract object is created to relate multiple objects, such that 
when a first event (e.g., deleted or moved) occurs to a first object, a second object may access the 
contract object to effect any corresponding changes according to the first event. 

Concrete 

According to the Interim Guidelines for subject matter eligibility, published on 
November 22, 2005, the requirement that the result be "concrete" means that "the process must 
have a result that can be substantially repeatable or the process must substantially produce the 
same result again. . . . The opposite of 'concrete' is unrepeatable or unpredictable" (see Interim 
Guidelines, page 22). The Applicant asserts that this requirement is met: the creation of a 
contract object to relate a first object and a second object results in an automatic update to the 
second object when a first event occurs to the first object. 
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Because the claimed invention produces "a useful, tangible, and concrete" result as 
defined in the Interim Guidelines for subject matter eligibility, published on November 22, 2005, 
as well as in State Street Bank & Trust Co. v. Signature Financial Group Inc., the Applicant 
believes that claims 17 and 44, and their respective dependent claims, are patentable under 35 
U.S.C. § 101. 

CLAIM REJECTIONS - 35 U.S.C. § 103(a) 

Claims 17, 18, 20, 26, 44, 45, 60, 61, and 68-70 stand rejected as being obvious over 
Gorur in view of Iyengar. The Applicant respectfully disagrees for the reasons that follow. 

Claim 17 recites "removing the entry from the transaction log after the contract object is 
created" (see specification, page 9, lines 31-32). Claim 44 recites similar features. 

The Examiner acknowledges that Gorur does not disclose removing the entry from the 
transaction log (see Off ice Action dated March 26, 2007, page 6, paragraph 15). The Examiner, 
however, alleges that Iyengar discloses the removal feature as recited in claim 1 7, citing Page 
333, Column 2, Section 2.3. 

But Iyengar does not disclose removing an entry from a transaction log. Iyengar instead 
discloses recording cache transactions in a log file (see Iyengar, page 329, column 2, fifth 
paragraphs from top of the page). The "cache transactions" mentioned by Iyengar refer to any 
invocation of a cached API function by an application program, such as Web servers and data 
bases (see Iyengar, page 329, column 2, fifth paragraphs from top of the page, and Abstract). 
Specifically, Iyengar discloses writing cache transaction records using the standard C library call 
fwrite. Each cache transaction record may be flushed to a disk as soon as the cache transaction 
record is generated, to prevent the transaction records from being lost if the cache process fails. 
An alternative approach is to accumulate several transaction records in a buffer before flushing 
the buffer to disk. This latter approach incurs lower overhead than the former, but has the 
disadvantage of losing those transaction records that have not yet been flushed to the disk (see 
Iyengar, page 333, column 2, section 2.3). In other words, Iyengar records cache transactions in 
a log file stored in a disk by writing and flushing to the disk the cache transactions. Iyengar 
discloses only recording the transactions in a transaction log; Iyengar does not teach removing 
any transaction record from the transaction log as recited in claim 17. 
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The Examiner further alleges that one of ordinary skill in the art at the time of the 
invention would have been motivated by Iyengar to reduce overhead costs related to software 
objects of Gorur (see Office Action dated March 26, 2007, page 4, paragraph 13). But the 
suggested motivation by the Examiner teaches away from the claimed invention, as discussed 
below. 

The claimed invention uses a transaction log to enable the rebuilding of a file system in 
case the file system is damaged before it reaches a stable state. An entry may be removed from 
the transaction log after the corresponding object manipulation is finished, and the file system is 
in a stable state. For example, as illustrated in FIG. 6, "[i]f transaction log 605 is used to rebuild 
file system 335, then when file system 335 begins to recover from the failure, file system 335 
may access transaction log 605 and determine which transactions were underway when the 
failure occurred. Entry 620 can be used to retry creating contract 215, completing the 
relationship between file 115 and collection 205. Once contract 215 is established, entry 620 can 
be removed from transaction log 605, as there is no need to recreate contract 215. If entry 620 
were the only entry in transaction log 605, then file system 335 would know that file system is 
fully restored after entry 620 is removed, and normal file system operations may commence" 
(see specification, page 9, lines 27-33). 

In other words, an entry may be removed from the transaction log after the corresponding 
object manipulation is completed, to indicate that the corresponding object has been recreated in 
the file system. Once all the entries are removed from the transaction log, the file system has 
been fully restored, and normal file system operations may commence. Put yet another way, the 
claimed invention removes an entry from the transaction log to indicate when that transaction has 
been completed and the file system may have been restored, so that normal file system 
operations may commence in case of file system failures. This is in contrast to the alleged 
motivation relied upon by the Examiner, which is to reduce overhead costs related to software 
objects of Gorur. If, as the Examiner suggests, a goal is to reduce overhead costs, maintaining a 
transaction log does not achieve this goal. Transaction logs are expensive to maintain, and are 
rarely needed. The cost of maintaining a transaction log would increase, rather than reduce, 
overhead costs. 

Claim 32 recites "A computer-implemented method according to claim 17, further 
comprising using the entry to reconstruct the contract object after the contract object is lost." 
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The Examiner alleges that it is obvious to use Gorur's persistent log to reconstruct a 
contract object to overcome the shortcoming of the prior systems as described by Yin and 
Iyengar by reducing overhead cost (see Office Action, page 10, paragraph 28). 

But Gorur's persistent log dialog 240 is "a persistent message forum that allows users to 
communicate information about the contract to increase understanding of the focus and context 
of the contract or to negotiate details of the contract. In various example, the dialog can be used 
to (1) negotiate the terms of a contract, (2) communicate the details and expectations of an 
assignment, or (3) coordinate efforts of an activity (see Gorur, Page 5, [0073])." Gorur's dialog 
240 includes Entry Person, Date Time, and Message attributes. The Entry Person attribute 
identifies the name of the person that entered text into the dialog; the Date Time attribute 
identifies the date and time text was entered into the dialog; and the Message attribute includes 
the text message that was entered into the dialog (see Gorur, page 5, % 74). In other words, 
Gorur's persistent log is not used to reconstruct a contract object after the contract object is lost 
as in claim 32, but rather used as a communication forum to negotiate details of a contract. 
Nowhere has Gorur, Yin, or Iyengar disclosed using a log to reconstruct a contract object after 
the contract object is lost. 

Furthermore, the suggested motivation by the Examiner teaches away from the claimed 
invention. The claimed invention uses a transaction log to enable the rebuilding of a file system 
in case the file system is damaged before it reaches a stable state. If, as the Examiner suggests, a 
goal is to reduce overhead costs, maintaining a transaction log does not achieve this goal. 
Transaction logs are expensive to maintain, and are rarely needed. The cost of maintaining a 
transaction log would increase, rather than reduce, overhead costs. 

As the combination of Gorur and Iyengar does not all the elements in claims 17, 18, 20, 
26, 44, 45, 60, 61, and 68-70, claims 17, 18, 20, 26, 44, 45, 60, 61, and 68-70 are patentable 
under 35 U.S.C. § 103(a) over Gorur in view of Iyengar. Claims 17, 18,20,26,44,45,60,61, 
and 68-70 are allowable. 

Claims 19, 21-24. 27-30, 32, 46. 48, and 49 stand rejected under 35 U.S.C. § 103(a) as 
being obvious over Gorur and Iyengar, and further in view of Yin. The Applicant respectfully 
disagrees for the reasons that follow. 

Yin discloses a centralized contract management system which automatically and 
continuously manages orders and contracts among trading partners. Yin's system knows all the 
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relevant upstream and down stream contracts for both contracting parties, as well as all the 
business rules, such that the system notifies and/or reminds the trading partners of critical events 
and activities. Specifically, Yin discloses the system uses a hub and spoke architecture where all 
contract information between trading partners is stored at the hub and all orders between the 
trading partners go through the same hub {see Yin, page 5, f| 74, 75, 79, and FIG. 1). 

As for claims 22-23, 28-30, and 48-49, the Examiner alleges that Yin describes a contract 
object comprising locators and identifiers, citing FIG.9, Contract class, ProviderAccountld, 
ConsumerAccountld, and ParentContractld {see Office Action, page 9, paragraph 25). But Yin's 
locators and identifiers, such as ProviderAccountld, ConsumerAccountld, and Contractld, are 
not stored in the contract object or the first/second objects (i.e., trading partners) as established in 
the claims. Instead, Yin's locators and identifiers are stored in the database 370 in the hub 
component 1 06 of system 300 {see Yin, page 6, f 91, page 8, ][ 138, and FIG. 3]). Yin's hub is a 
central information processing system to manage orders and contracts among trading partners, 
rather than a contract object or the first/second objects {see Yin, page 5, \ 79, and FIG. 1). 

Furthermore for the reasons discussed above, the suggested motivation by the Examiner- 
reducing overhead costs described by Iyengar, teaches away from the claimed invention. The 
claimed invention uses a contract object to coordinate relationships between multiple objects, 
resulting in an automatic update to one object when an event occurs to another object. The 
claimed invention also uses a transaction log to enable the rebuilding of a file system in case the 
file system is damaged before it reaches a stable state. The claimed invention does not concern 
about reducing overhead costs. If, as the Examiner suggests, a goal is to reduce overhead costs, 
maintaining a transaction log does not achieve this goal. Transaction logs are expensive to 
maintain, and are rarely needed. The cost of maintaining a transaction log would increase, rather 
than reduce, overhead costs. 

Claims 54 and 62 stand rejected under 35 U.S.C. § 103(a) as being obvious over Gorur in 
view of Iyengar and Yin, and further in view of Kulkarni. These rejections are respectfully 
traversed for the reasons given above for the patentability of the independent claims 17 and 44. 
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For the foregoing reasons, reconsideration and allowance of claims 17-24, 26-30, 32, 44- 
46, 48, 49, 54, 60-62, and 68-70 of the application as amended is requested. The Examiner is 
encouraged to telephone the undersigned at (503) 222-3613 if it appears that an interview would 
be helpful in advancing the case. 



MARGER JOHNSON & McCOLLOM, P.C. 
210 SW Morrison Street, Suite 400 
Portland, OR 97204 
503-222-3613 
Customer No. 45842 



Respectfully submitted, 



MARGER JOHNSON & McCOLLOM, P.C. 




Reg. No. 43,054 



Docket No. 6647-049 



Page 16 of 16 



Application No. 10/626,097 



